Pico loader #877
Pico loader #877
Conversation
Might fix that in short order! No controls tho... |
Daft-Freak
force-pushed
the
pico-loader
branch
from
ae568a5 to
243e6c7
Compare
😱 |
A lot of that is going to be "distraction time" (or was this the distraction?)... But yeah. https://fosstodon.org/@Daft_Freak/109984773682008272 |
|
I wonder if we can get a USB PID for "32blit SDK on RP2xxx" 🤔 (Considering that the exposed device is always the same... and the pythons have one). I'm getting a little tired of doing Edit: the second field in the form being company name would suggest that I cannot... |
|
See https://github.com/raspberrypi/usb-pid They recommend using iManufacturer and iProduct (which you can set to whatever you want) for devices that have a CDC serial interface. |
|
Mmm, but this is a composite CDC+MSC device. We're currently defaulting to the very placeholder 0xcafe from the tinyusb examples. Also it would seem that using the manufacturer/product strings doesn't work on windows. (I only get a manufacturer of "Microsoft" and no product from pyserial) |
Which currently doesn't happen
Right now it's just a BLIT header instead of boot2, built at a 512k offset to allow launching one thing without position independent code
Seems a bit weird, but needed to get the right framebuffer size
It's... not unusable
Launches the first thing it finds. has some fixed locations for API consts/data.
No update/tick, page-flipping doesn't work, firmware uses 130k RAM
Only builds one at a time, which causes less problems. Controlled by PICO_STANDALONE_UF2/PICO_BLIT in blit_executable or BLIT_EXECUTABLE_PICO_STANDALONE_UF2/BLIT_EXECUTABLE_PICO_BLIT globally
This reverts commit dd0fec9.
firmware now reserves 32k of RAM (may need less)
larger project for the future: share this code
So that it actually does the thing it's supposed to do
This has been broken since set_framebuffer...
This is the only way for switching between two double-buffered modes to work
It's all low-level stuff the loader should've done
It does things we need to not crash and doesn't do any of the things that caused problems on 2350
This is as big as we can handle with the current translation setup
Avoids faulting when exiting something using audio
The tools assume that any output during this command is an error
Shares a bit with PROG, but a bit simpler
Really useful for sending more than one file...
We didn't need this previously because it never tried to render anything
Currently for progress bars, but maybe a menu later?
the normal render/display update gets a chance to run, so this is easy
This also works with the previous fix
Sometimes we're going to lock out rendering for a while...
Can't display progress unless we start breaking up the erase
Though there ends up being a lot in executable.cmake as blits still need the SDK
Daft-Freak
force-pushed
the
pico-loader
branch
from
c00e53a to
af4aa05
Compare
I can certainly ask RPi for an allocation! Edit: Done. It's a bit of a long shot since this is an SDK and not a single device, but you don't know if you don't ask. |
I finally untangled this!
Building with
BLIT_EXECUTABLE_PICO_BLIT=1creates .blit files instead of .uf2s, these are mostly portable between devices. (The framebuffer size is still set a compile time, so if you have the board set to PicoSystem (the default) the resulting .blit won't run on a device with a > 240x240 display. PicoVision is unaffected by this as its framebuffer is in the PSRAMs)Installing multiple blits requires manually building them for different offsets (
-DBLIT_EXECUTABLE_PICO_BLIT_OFFSET_KB=x), the launcher is built at a lower offset be default. On RP2350-based devices address translation is used to support running blits from any offset. Not much hardware to try that on though...Some of the CDC API used by the tools is supported and can be used to flash blits onto a PicoSystem. This requires manually specifying the port as the tools don't recognise the VID/PID. (Which should probably be changed to something other than 0xCAFE first).
There's currently no menu but the "hold HOME to exit" feature is there. (If the device has a HOME button... Sorry PicoSystem users.)
Still a lot of missing bits and duplicated logic with the -stm32 port, I have some plans to clean that up a bit. Need to see what it looks like complete first though...
(May edit if I remember more details... Been working on this for > 1.5 years...)
EDIT:
PROG,SAVE,__LS,LNCHandERSE(noINFO,_RST,SWIT)